With the increasing complexity involved in the development of computer programs that embody very sophisticated business logic, specification of the requirements of these programs before they are actually built, i.e., programmed into computer readable code is important to timely and cost-effective production of these systems.
As organizations are forced to do more with less, the need to deliver such applications on-time and on-budget without sacrificing quality presents a bigger challenge than ever before. One of the major problems in these fields is system definition, i.e., the effective identification of accurate, complete and unambiguous requirements for the system or application. This is especially true of applications used on the Internet. These applications must meet requirements related not only to graphic design, content and usability, but also related to complex scenarios of user system interactions that are not complete and accurate requirements from outset and may not even be documented before starting the application design.
Traditional software development falls typically into several main disciplines. The first is known as the “waterfall” software development life cycle approach. The second approach attempts to improve the effectiveness of the waterfall approach by introducing prototypes into the development lifecycle early in the development cycle. Each of these approaches is associated with significant problems.
The waterfall approach is a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back. This phase of development is analogous to the flow of water over a waterfall; it cannot flow back to the top of the waterfall. In the waterfall design approach, the requirements gathering phase typically results with capture of requirements on paper documents. Typically, the system designers generate a paper-based design from the paper-based requirements. The system developers then interpret the paper-based design and convert it into executable computer code. Typically, the executable code is then delivered to the testers, who then evaluate the code to determine if the resulting computer application meets the requirements.
While waterfall development allows for departmentalization and managerial control, it does not allow for much reflection or revision. Iterations of the design process require iterations of the entire process. However, once an application is in the testing stage, it is very difficult to go back and change something that was not well thought out in the concept stage. Also, typically, problems are not discovered until system testing, and requirements must be fixed before the system is designed. Requirements evolution makes the development method unstable. Often during the design and code writing phases, requirements, inconsistencies, missing system components and unexpected development needs are discovered. Also, system performance cannot be tested until the system is almost coded, and under-capacity may be difficult to correct. For these reasons the standard waterfall model has been associated with the failure or cancellation of a number of large systems.
Known alternatives to the standard waterfall design approach include modified waterfall approaches that include those that start with a very rough notion of the system and become more detailed over time, analogous to going over several smaller waterfalls (spiral waterfall design); and those that include overlapping phases and sub-projects (modified waterfalls).
Other known design approaches includes the staged delivery approach, in which the designer reviews the concept, requirements analysis, and architectural design phases, and then implements these phases, shows them to the customer as the components are completed, and then goes back to the previous phase(s) if needed.
All of these waterfall type approaches suffer from the same or similar problems, however. The iterative approach through the phases, even when overlapped, results in static requirements being interpreted into static designs and developments. Because the requirements for most systems are not well understood in the beginning, the costs for development often become excessive and delivery schedules originally estimated must be revised. Finally, because complex systems typically are not well understood in terms of their actual implemented behaviors, it is only through actual interaction with the system that the system designers and business analysts truly begin to understand what has been built. Although the lessons learned may be valuable during waterfall implementations, they cannot easily be taken advantage of, due to the prohibitive costs of re-factoring the designs and implementations to reflect the new requirements that spring from these lessons.
The second general approach, the prototyping of critical parts of the application, was developed, partly in response to the problems associated with the waterfall and modified waterfall approaches. As used herein, the term prototype, and its variations, in the context of the design of computer applications means the use of some form or stage of application code, or the use of static images to represent computer screen display.
The prototyping of critical parts, referred to sometimes herein as code prototyping, also was developed in response to awareness in the field of the invention that software product development tends to move along four paths: (1) ideas to product; (2) low technology to high technology; (3) drawings to code; and (4) appearance and behavior to performance. In the code prototyping approach, a prototype code is built to test the results of the planning phase, during which the developers attempt to understand the users and the users' needs and how those were to be addressed in the software application. The prototype code is then measured to see how the user reacts and understands the developers work, and is analyzed to see which parts of the prototype are doing well and which parts are not. In this prototyping approach, the prototype is actually code that is intended to accomplish the intended purpose of designated parts of the overall software application, and is therefore referred to herein as a “coded prototype.”
The prototyping approach also has been associated with numerous problems, foremost among them is that prototypes are typically written in computer languages that only programmers can understand and use. Thus the prototypes are still developed as traditional computer programs, by programmers. This has several drawbacks. The first drawback is that business analysts, who are the people most likely to understand the needs and desires for the computer application, cannot develop the prototype without reliance on computer programmers, and must translate and communicate these needs and desires to computer programmers in order to have them construct the prototype. This communication is traditionally inefficient and translation errors tend to be introduced because of the differences in the interpretation of the needs and desires for the prototype between two constituencies with differing backgrounds and skill sets. Second, in many organizations, skilled programming resources are preferentially assigned to fixing existing computer systems or completing development of systems that are soon to be placed in production. Thirdly, programming resources need potentially expensive hardware and software tools to accomplish their work. Fourthly, because prototypes are frequently constructed using the same infrastructure that the eventual application will be deployed upon, prototyping efforts are frequently delayed until strategic hardware acquisition, development software acquisition and training have been completed.
Yet another problem with prototyped systems is that they tend to become a replacement for actual development of the envisioned system. There is a tendency to attempt to field a completed, or near-completed prototype. Because the programmers were originally building just a subset of the system for demonstration purposes, short cuts typically are taken in this phase that lead to systems that do not scale well and have significant performance problems.
Yet another problem with coded prototypes is that they suffer from poor documentation, often because the prototype and the requirements are not represented within the same context.
Another problem with coded prototype based developments arises from the tendency for difficult problems to be pushed to the future, and not solved by the time of product completion, so that the initial hope of the prototype is not met by the subsequent product.
Because of these limitations, another prototyping approach, referred to as static prototyping, has evolved. In this approach, only an image of the user interface of the prospective computer application is developed. This image may be created using commonly available drawing and diagramming software, and may be created without some of the drawbacks associated with employing programming resources to create a coded prototype. Prototypes created in this manner, however, suffer from additional drawbacks. Foremost among them is that such static prototypes created with drawing and diagramming software are unable to convey to stakeholders an understanding of or how the application will behave. Prototypes constructed in this manner do not exhibit many of the interactive behaviors of computer applications, e.g., navigation from screen display to other screen display, computation, storage and retrieval of data. They are therefore referred to as “static image prototypes” herein. It is commonly known in the field of the current invention, that stakeholders are much more apt to identify potential errors or omissions in the early phases of software development if they are permitted to interact with a prototype that does exhibit these interactive behaviors.
To summarize the forgoing discussion of background art; coded prototypes suffer from drawbacks derived from the need to utilize computer programmers in their construction and static image prototypes suffer from drawbacks derived from the fact that they are inherently not interactive.
In addition, the evolutionary delivery design process, a cross between evolutionary prototyping and staged delivery, is known.
Within the context of the above described software design approaches, many systems analysts simply use a pad of paper to record requirements they gather from the eventual users of the computer program being envisioned for development. Still other systems analysts use word-processing programs to write specifications in a prose style. Several design methodologies have emerged to graphically describe the use of iteration with computer programs, and how these programs are to be organized internally. Ultimately, these specifications all coalesce to static representations of the proposed or prospective computer program that computer programmers must either read on paper, or read from a computer screen to gain an understanding of what the systems analysts interpreted what the users meant when they designed the system. The programmers must then write the code that represents their best interpretation of what the systems analysts and the users meant when the static system specification was created. Finally, after the computer programmers create the computer software code, it is tested by the systems analysts and users to determine if the programmers' interpretation of the system specification (that is, in turn, the system analysts' interpretation of the requirements from users of the proposed computer system) meets the users' requirements. In complex systems that must interact with multiple users, playing different roles, and in turn interact with multiple other computer programs, also playing different roles, the probability of interpreting the users' requirements correctly the first time is quite remote. This necessitates frequent code changes and reinterpretations, first by the users, second by the systems analysts and third, by the computer programmers. This cycle is repeated until the computer programmers rewrite the software enough times to embody what the users require of the system. The reliance on static documents to transfer the requirements into a correct computer program results in repeated cycles of development. These cyclic and redundant development activities inflate the cost of the resulting system.
As such, the programmers, at the end of the cycle of research and development of a large program or system, typically are left to discover all of the ambiguous, hidden and conflicting requirements as they actually write software code. This invariably leads to failures of the code to correctly embody the users' requirements, longer development cycles, increased costs and lower quality end products.
In addition, known computer application development approaches typically do not include input from all of the various stakeholders. Rather, it is generally business managers who determine the need for the application, and then business analysts translate these needs into the domain specific jargon appropriate to the problem being solved, and finally the computer programmers translate the business domain information into executable code. This serial process leads to misunderstandings, unresolved issues and misconceptions.
Finally, another problem with known software application development approaches is that software testers are provided with only a document for use in developing quality assurance and acceptance tests, and acceptance testing can occur only at the end of the development cycle. This is an additional source of delay and problems because the quality assurance engineers are then required to conduct there own interpretation of all of the prior development work.